Nice. I was also thinking about some git describe integration (especially for presuming current_version if there is none given explicitly).

What's your opinion on using the flag --annotate instead of --tag-message/TAG_MSG ?

If you use git tag --annotate, it will prompt for a message like git commit. So thought it was better to pass in the message immediately.

You could also provide the option to (GPG) sign the tags.

Sorry, I meant naming the flag for bumpversion --annotate, as in bumpversion --annotate "myfancyproject v{new_version}"

Sure, --sign should also be supported.

Another option, maybe achieving both with more configurability:

What about keeping that generic (looking at about mercurial support, which I don't know that well) and providing a --git-tag-options "--sign --annotate v{new_version} --verify -u mygpgkey --force" flag for configuring things that are git-specific ?

Agreed, sounds good. I'll update accordingly.

Maybe check whether mercurial supports a similar workflow first. I'd like to keep general configuration generic and special configuration special.

Sent from my pocket calculator

Am 22.04.2013 um 12:50 schrieb Gert Van Gool [email protected]:

Agreed, sounds good. I'll update accordingly.
—
Reply to this email directly or view it on GitHub.

I'm not entirely happy at the moment with the escaping, but you can pass anything to the underlying command (git tag or in the future hg tag).

Maybe you have an idea what I need to change in the parser to fix this:

~/env/test/bin/bumpversion --tag-options '"-m \"bumpversion2 v{new_version}\""'

I was hoping to get to ~/env/test/bin/bumpversion --tag-options '-m "bumpversion2 v{new_version}"', but you get this error:

usage: bumpversion [-h] [--config-file FILE] [--bump PART] [--parse REGEX]
                   [--serialize FORMAT] [--current-version VERSION]
                   [--dry-run] [--new-version VERSION] [--commit] [--tag]
                   [--message COMMIT_MSG] [--tag-options TAG_OPTIONS]
                   [file [file ...]]
bumpversion: error: argument --tag-options: expected one argument

Any plans on completing this?

@ekohl, you're right. this is a long-standing feature wish. I'm not using annotated tags myself, so getting this right involves a bit of research for me (how are people using annotated signed tags, how about a good default message, etc.).

Patches including tests and documentation are always welcome though :)

@gvangool are you going to finish this or do you mind if I take your code, rebase it and complete it?

@peritus my use case is having a meaningful git describe and that uses annotated tags. This code looks like a good start, though I don't like exposing the raw options. I'm leaning toward simplicity and just expose a tag_message template similar to the commit message and tag_signed boolean flag.

@ekohl no problem, go wild! I'm not using it at my current job. So haven't looked at it in while.

Yes, I'm also not in favor of exposing raw options. Simplicity is king, but so is a universal, versatile, complete solution.

@ekohl If you urgently need this, I'd be happy to collaborate with you on a patch to accelerate this.

@peritus I wouldn't say urgently, but I would be interested. I will try to finish the rebase into a minimal working version and submit a new pull request. There we can discuss it further.

Sounds great, looking forward to it!

I opened #58

@gvangool This has gone stale, any plans for rebasing?

@peritus What are your current thoughts on this vs. #58 vs. #74?

@peritus Just to note that annotated tags are an absolute showstopper for me, no point adopting bumpversion without this feature imho. I'm sure many others feel the same. Anything I can do to help get this in please shout!

@peritus I'd like to bump this as well. We also prefer using signed release tags at my current job.